这篇文章争取用比较浅显易懂的语言来描述 Dubbo，但是并不涉及具体的操作步骤，本人只是希望大家能对 Dubbo 这个概念有个更好的理解，那么之后你在使用 Dubbo 的时候才不会那么困惑。
Dubbo 是什么？
Dubbo 是阿里出的。为什么 Dubbo 成名了呢？阿里内部使用了它好长时间,一直木有对外公开，后来阿里面的工程师离职了，就把 Dubbo 给带出来了，后来阿里也就把 Dubbo 公开了。
官方说法，Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案。RPC 指的是远程调用协议，也就是说两个服务器交互数据。
Dubbo 能做什么？
那么，我们究竟是在什么地方使用到的 Dubbo 呢？大家请看下面的流程图：
简单来说，用户发送的请求转交给 Nginx，然后 Nginx 决定将请求发送那个服务器（此处为 Tomcat），然后 Tomcat 将请求发送给 Dubbo，由它来决定继续调用哪个 service 层去数据库读取数据。
相信大家对于 Dubbo 作用于何处应该有个大体的了解了。
Dubbo 的使用原理解析
- Consumer：消费者
- Provider：生产者
- Registry：注册中心（相当于之前的等待–wait 和唤醒—notify）
- Monitor：监控中心
执行的顺序： - 0：先启动生产者；
- 1：生产者将自己启动的消息报告给注册中心；
- 2：消费者启动，通知注册中心；
- 3：注册中心通知消费者有生产者了；
- 4：消费者消费(调用方法)；
- 5：生产者和消费者将自己的调用信息和被调用信息发送监控中心；
要说明的是，必须要先启动生产者，就像咱们平常生活一样，只有生产了某样东西你才能去消费，对吧。
可能会有读者有疑问，这个生产者、消费者和上面的流程图有什么关系，或者说，生产者、消费者对应流程图中的哪个部分呢？
在这里我想用一些拟人化的手法解释一下，效果或许会更好点。
生产者相当于 service 层，拿上面的流程图来说，可以看成有三个生产者：service、service_2 和 service_3。
随便拿其中一个生产者举例子，比如说 service_2，它能够利用 dao 层去数据库取出数据，也就是说生产者可以拿到他人需要的数据，这也正符合「生产者」这个名词，service_2 可以 “生产” 出消费者需要的东西（数据）。
生产者在产生之后会先去 Registry 这个地方去「报到」，告诉Registry 它能生产哪些物品（即取出哪些数据）。
消费者相当于 controller 层，暂且把消费者叫做 c。如果 c 想要买某样东西（可以把这样东西看成数据库中的数据），但是不知道该去哪里买，那么这个时候，它就会去 Registry 这个地方，告诉 Registry 它需要这个东西。
由于生产者产生之后在这里「报到」过了，所以 Registry 会告诉消费者 c，生产者 service_2 可以给你你想要的东西（数据），然后消费者 c 就会去找生产者 service_2 而不去找其他两个生产者，这样一来 service 层的压力就会小很多。
不知道这么说大家有没有能够明白一点。
还有就是，不论是生产者还是消费者，产生之后都要去 Registry 报到，不然就是黑户哟~
另外，它俩都要受到 Monitor（监控中心）的监控，以监控它俩是否离奇失踪，哈哈。
Dubbo 的存在简单来说就是要减小 service 层的压力。